A Formally Verified OS Kernel. Now What?

Last year, the L4.verified project produced a formal, machinechecked Isabelle/HOL proof that the C code of the seL4 OS microkernel correctly implements its abstract implementation. In my presentation I will summarise the proof together with its main implications and assumptions, I will describe in which kinds of systems this formally verified kernel can be used for gaining assurance on overall system security, and I will explore further future research directions that open up with a formally verified OS kernel. 1 A Formally Verified OS Kernel Last year, we reported on the full formal verification of the seL4 microkernel from a high-level model down to very low-level C code [5]. To build a truly trustworthy system, one needs to start at the operating system (OS) and the most critical part of the OS is its kernel. The kernel is defined as the software that executes in the privileged mode of the hardware, meaning that there can be no protection from faults occurring in the kernel, and every single bug can potentially cause arbitrary damage. The kernel is a mandatory part of a system’s trusted computing base (TCB)—the part of the system that can bypass security [9]. Minimising this TCB is the core concept behind microkernels, an idea that goes back 40 years. A microkernel, as opposed to the more traditional monolithic design of contemporary mainstream OS kernels, is reduced to just the bare minimum of code wrapping hardware mechanisms and needing to run in privileged mode. All OS services are then implemented as normal programs, running entirely in (unprivileged) user mode, and therefore can potentially be excluded from the TCB. Previous implementations of microkernels resulted in communication overheads that made them unattractive compared to monolithic kernels. Modern design and implementation techniques have managed to reduced this overhead to very competitive limits. A microkernel makes the trustworthiness problem more tractable. A welldesigned high-performance microkernel, such as the various representatives of ? NICTA is funded by the Australian Government as represented by the Department of Broadband, Communications and the Digital Economy and the Australian Research Council through the ICT Centre of Excellence program the L4 microkernel family, consists of the order of 10,000 lines of code (10 kloc). We have demonstrated that with modern techniques and careful design, an OS microkernel is entirely within the realm of full formal verification. The approach we used was interactive, machine-assisted and machine-checked proof. Specifically, we used the theorem prover Isabelle/HOL [8]. Formally, our correctness statement is classic refinement: all possible behaviours of the C implementation are already contained in the behaviours of the abstract specification. The C code of the seL4 kernel is directly and automatically translated into Isabelle/HOL. The correctness theorem connects our abstract Isabelle/HOL specification of kernel behaviour with the C code. The main assumptions of the proof are correctness of the C compiler and linker, assembly code, hardware, and boot code. In my presentation I will give an overview of this proof and reflect on some of the lessons learned in this project. For instance, one question with any verification is: what does the specification say, what level of detail does it contain, and why? The current abstract specification of the seL4 kernel was written with the following goals: – abstract from data structures and implementation, aim to specify what, not how; – have enough detail for functional correctness proofs of applications on top of seL4; – have enough detail for users to understand results, error conditions and error codes Especially the latter two goals mean that the abstraction level of this specification is at points lower than one might wish for a specification. For instance, to be able to show functional correctness of code on top of seL4, we do not want to use nondeterminism too liberally in the specification. If the kernel is allowed to do either A or B nondeterministically for a certain system call, then user programs will always need to handle both cases, even though in the implementation it will usually be possible (and desired) to predict which case is taken. We have therefore usually tried to include enough data in the abstract specification layer to precisely predict kernel behaviour. This draws a small number of rather arcane implementation details to a high specification level. In hindsight it is precisely these cases that users of the kernel now find hard to understand and that are candidates for future evolvement and simplification of the seL4 API. Some of these were eliminated in early API iterations (precisely to achieve an nicer specification), but others were deemed too hard or necessary at the time. An area where nondeterminism is more reasonable is the pure indication of failure due to implementation restrictions not visible at an abstract level. In seL4 this would mean the system call either fully succeeds or has no effect and returns with an error code. This is significantly simpler to handle for the user than two different behaviours with state change. On the other hand, this means for user programs that such system calls will always need error handling code. Hence, there is still a trade-off to be made between predictive precision and elegant abstraction. Another way to achieve more abstraction is to focus on specific aspects of the system. We have previously published different versions of a high-level access control model of seL4 [3,2]. These models abstract from message passing, memory content, and nearly all other behaviour of the system. They only record which objects have access to which capabilities. This in turn determines which system calls a thread may perform and which objects it may access. If system calls and capabilities are additionally tagged with information flow attributes, it becomes possible to reason about the authorised information flow behaviour of a system without knowing its full functional behaviour. Another potential abstraction of the kernel may be purely its message passing behaviour, possibly ignoring or disabling shared memory. This could be used to implement abstract communication formalisms such as the pi calculus.